主题
对比 JavaGuide《RAG 文档处理与切分策略》（另见自己的 chunk策略笔记）与二哥《Agent 的 RAG 遇到 PDF 怎么办？》及小林《RAG 最难的地方》。
多版对比
这一簇两边高度一致，二哥基本是 JavaGuide 的口语压缩版，冲突极少。
开场判断句：二哥的「PDF 是排版格式，不是数据格式」一句话点破本质，比 JavaGuide 六环节链路（上传 → 格式校验 → Layout 解析 → 清洗 → Chunking → 元数据 → 入库）更适合当答案第一句。
核心难点共识：多栏 PDF 的存储顺序 ≠ 阅读顺序，必须用版面感知解析器；表格和图片单独处理——表格转 Markdown 或结构化 JSON 并带页码坐标，图片走多模态路径。
多模态三条路径，JavaGuide 独有的系统化：图转 CLIP 向量 + 原图回传、多模态模型生成文字描述 + 按描述检索、多向量检索——收在一句判断里：摘要用于检索，原文用于生成。
延迟与成本权衡，二哥独有：解析结果入库缓存；查询时先混合检索 + 重排，证据不足才触发多模态精读原页——把贵的能力放在按需路径上。JavaGuide 独有评测意识：切分参数（如子块/父块大小）没有万能值，页级切分在某金融文档评测里只比基线高 0.3-4.5 个百分点——参数必须本地评测，别信博客。
小林：补了最生动的失败案例——pypdf 这类库只做文本流提取，双栏和表格会解析成「型号 内存 价格 iPhone 15 8GB 5999」式的乱序乱码；替代路径是 pdfplumber / unstructured，扫描件上 OCR，高价值文档（合同、财报、专利）可以上多模态视觉模型读截图，但成本高几十到上百倍、只值得给关键文档用。判断句值得背：文档预处理的代码量往往比 RAG 核心逻辑还多。
结论：开场判断句和分层成本策略不变，失败案例用小林的「乱序乱码」——比抽象说「解析困难」有说服力得多。
最优题解
PDF 的根本问题是它是排版格式不是数据格式：多栏、表格、图文混排会让「存储顺序」和「阅读顺序」不一致，直接抽文本就把结构抽丢了。所以链路是：先判类型（电子 PDF 直接解析，扫描件上 OCR 或多模态模型），再用版面感知解析保留阅读顺序和结构，表格转结构化带页码坐标，图片走「摘要用于检索、原文用于生成」的多模态路径。
成本上做分层：解析结果入库缓存；查询先走混合检索加重排，证据不足才触发对原页的多模态精读。切分参数没有万能值——同样的页级切分在一份金融文档上只带来个位数的准确率提升——所以 chunk 大小、父块子块这些参数必须在自己的语料上评测后定。
追问链
追问：扫描件和电子 PDF 处理上差在哪？ 参考答：电子件文本层直接可抽，重点是版面还原；扫描件先过 OCR 或直接喂多模态模型，重点是 OCR 质量校验（双引擎对比、关键字段核对），错误会一路带进索引。
追问：表格为什么不能当普通文本切块？ 参考答：表格的语义在行列交叉关系里，切开就丢；整表作为独立块并保留表头和页码坐标，检索命中后整块返回，行数太多再做行级拆分但保留表头行。
我的理解
这题两边几乎不冲突，最优解就是「二哥的开场句 + JavaGuide 的链路和评测意识 + 二哥的成本分层」。特别要留下 JavaGuide 那个反直觉数据：页级切分只提升个位数百分点——它证明「切分策略玄学」要靠本地评测破除，这句在面试里比背参数表高级得多。和我自己的 chunk策略笔记互为补充：那边管通用切分，这边管 PDF 特化。